The present invention relates to networks, and more particularly to forwarding multicast frames over an Ethernet bridged network infrastructure.
An Ethernet network with a bridged infrastructure improves networking performance, i.e., bandwidth, by separating point to point or unicast traffic. Such a network, as shown in FIG. 1, has one or more hosts coupled to a hub or common bus, with one hub being coupled to another via a bridge or switch. The bridge in turn is coupled via a router to the rest of the world, i.e., to the Internet, for example. However the bridged infrastructure does not separate, and thus improve the performance of, many to many or multicast traffic because the bridge, and hosts, treat multicast traffic as if it were broadcast traffic and floods it to all hosts. On the Ethernet network an Internet Protocol(IP)-multicast packet is encapsulated in an Ethernet multicast frame so that the IP-multicast packet shares the fate of the Ethernet multicast frame and is broadcast over the entire Ethernet bridged infrastructure.
A frame of data has a header, which includes an address space with a source address (the originator of the frame) and a destination address (the target of the frame), followed by data. For multicast traffic a network multicast packet is encapsulated within the frame as part of the data. The bridge does not look at the encapsulated network multicast packet, but merely at the source and destination addresses of the data frame header. The bridge maintains a forwarding table in which it contains a source address and a port of the bridge to which the source is coupled. The destination address of a frame is searched for within the forwarding table, and when found the frame is sent through the corresponding port to the host that has the destination address. If not found, the frame is broadcast--it is transmitted through all ports except the port on which it arrived. For broadcast frames, i.e., frames that are intended to be transmitted to all hosts, the destination address is tested to see if it falls within the broadcast address range, and if so the bridge broadcasts the frame. The bridge does not recognize multicast addresses, so multicast frames also are broadcast by the bridge.
The Ethernet system has 48 bits of address space that are divided up into:
(1) a broadcast address; PA1 (2) multicast addresses; and PA1 (3) unicast addresses.
The unicast addresses are the normal addresses, each address being assigned uniquely to a single board coupled to the network. A data frame addressed to a unicast address is forwarded by the bridge to the host to which the unique board identified by that address is coupled, while a data frame addressed to the broadcast address is forwarded to all hosts, and thence to all boards. But a multicast address is treated by the bridge as an unrecognized unicast address and broadcast.
The first facet of the problem in dealing with multicast addresses is on the host. Any frame addressed to a multicast address is received by every host, so that hosts that interface with the network may be interrupted for every multicast frame that appears on the hub, whether it is destined for them or not. This may be a major performance drain.
Next the bridge does not read the network level addresses that are encapsulated in the data frame, doing all its work at the data frame level, i.e., reading the data frame header. The bridge attempts to filter data frames between several hubs, each hub having one or more hosts attached to it. The bridge listens to source addresses on each hub and remembers on which bridge port it received such an address. The bridge then maintains a forwarding table which associates source address with the port on which it was heard. When it receives a data frame destined for a particular address, it searches its forwarding table to find a destination port. The bridge forwards the data frame to that port, if found, filtering the data traffic. If the bridge does not have the destination address in the forwarding table, or otherwise does not recognize the address, it treats the destination address as a broadcast address and outputs the data frame to every port. Thus bridges treat the multicast frames like broadcast frames.
Using a protocol entitled IGMP (Internet Group Management Protocol), as described in the Network Working Group Request for Comments (RFC) 1112, Appendix I (August 1989), hosts subscribe to a multicast session when they are polled by a router with a well-known specific multicast address. The multicast address from the router must be passed via the bridge as a broadcast frame to every host on every hub. If one or more of the hosts want to be part of a multicast session, the host or hosts respond by providing the address of the multicast session to which they want to subscribe. This information must be passed by the bridge back up to the router. If none of the hosts coupled to the bridge subscribe to a multicast session, then the router, when it receives a multicast frame, bypasses that bridge. However if one of the hosts coupled to the bridge subscribes to the multicast session, then the multicast frame is transmitted to the bridge which in turn, as discussed above, treats it as a broadcast frame and each host coupled to the bridge in turn accepts it as a broadcast frame.
There have been some attempts to solve this problem recently. Cisco Systems, Inc. of San Jose, Calif. sells bridges that work with a router which recognizes the network multicast address and performs the multicast polling at the router (network) level using a proprietary protocol between the bridge and the router.
Stephen Deering, in a 1988 paper entitled "Multicast Routing in Internetworks and Extended LANs" published by the Association for Computing Machinery, describes one technique prior to the IGMP protocol for multicasting in a simple bridged LAN using membership reports and a forwarding table algorithm. However the article does not describe how the bridge operates under the IGMP protocol, specifically what the interaction should be between the bridge and a router.
What is desired is a solution to the multicast problem in an Ethernet bridged network infrastructure using the IGMP protocol that assures that multicast frames are received only by subscribers to that multicast session without the use of proprietary hardware bridges or protocols.